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Be it known that we, ROBERT M. JUDD of 1062 Kingsport Drive, Wheeling, 
Illinois 60090; ENN-LING CHEN of 57 East Delaware Place, Unit 1601, Chicago, 
Illinois 60611 and Raymond J. Kim of 57 East Delaware Place, Unit 1601, 
Chicago, Illinois 60611, have invented a new and useful "MEDICAL IMAGE 
MANAGEMENT SYSTEM." 
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TITLE 

MEDICAL IMAGE MANAGEMENT SYSTEM 



FIELD OF THE INVENTION 

5 The present invention relates to medical imaging. Specific exemplary 

embodiments discussed relate to cardiac medical imaging. 



BACKGROUND OF THE INVENTION 

The description of art in this section is not intended to constitute an 

10 admission that any patent, publication or other information referred to 
herein is "prior art" with respect to this invention, unless specifically 
designated as such. 

Medical imaging is important and widespread in the diagnosis of 
disease. In certain situations, however, the particular manner in which the 

15 images are made available to physicians and their patients introduces 
obstacles to timely and accurate diagnosis of disease. These obstacles 
generally relate to the fact that each manufacturer of a medical imaging 
system uses different and proprietary formats to store the images in digital 
form. This means, for example, that images from a scanner manufactured 

20 by General Electric Corp. are stored in a different digital format compared 
to images from a scanner manufactured by Siemens Medical Systems. 
Further, images from different imaging modalities such as ultrasound and 
MRI are stored in formats different from each other. Although it is 
typically possible to "export* the images from a proprietary workstation to 

25 an industry- standard format such as "Digital Imaging Communications in 
Medicine" (DICOM) 3.0, several limitations remain as discussed 
subsequently. In practice, viewing of medical images typically requires a 
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different proprietary "workstation" for each manufacturer and for each 
modality. 

Currently, when a patient describes symptoms the patient's primary 
physician often orders an imaging-based test to diagnose or assess disease. 
5 Typically days after the imaging procedure, the patient's primary physician 
receives a written report generated by a specialist physician who has 
interpreted the images. The specialist physician, however, typically has not 
performed a clinical history and physical examination of the patient and 
often is not aware of the patient's other test results. Conversely, the 

10 patient's primary physician typically does not view the images directly but 
rather makes a treatment decision based entirely on written reports 
generated by one or more specialist physicians. Although this approach 
does allow for expert interpretation of the images by the specialist 
physician, several limitations are introduced for the primary physician and 

15 for the patient: 

1) the primary physician does not see the images unless he/she 
travels to another department and makes a request; 

2) it is often difficult to find the images for viewing because there 
typically is no formal procedure to accommodate requests to show 

20 the images to the primary physician; 

3) until the written report is forwarded to the primary physician's 
office, it is often difficult to determine if the images have been 
interpreted and the report generated; 

4) each proprietary workstation requires training in how to use the 
25 software to view the images; 
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5) it is often difficult for the primary physician to find a technician 
who has been trained to view the images on the proprietary 
workstation; 

6) the workstation software is often "upgraded" requiring additional 
5 training; 

7) the primary physician has to walk to different departments to 
view images from the same patient but different modalities; 

8) images from the same patient but different modalities cannot be 
viewed side-by-side, even using proprietary workstations; 

10 9) the primary physician cannot show the patient his/her images in 

the physician's office while explaining the diagnosis; and 
10) the patient cannot transport his/her images to another 
physician's office for a second opinion. 
It would be desirable to allow digital medical images to be viewed by 
15 multiple individuals at multiple geographic locations without loss of 
diagnostic information. 

"Teleradiology" allows images from multiple scanners located at 
distant sites to be transferred to a central location for interpretation and 
generation of a written report. This model allows expert interpreters at a 
20 single location to examine images from multiple distant geographic 
locations. Teleradiology does not, however, allow for the examination of the 
images from any site other than the central location, precluding 
examination of the images by the primary physician and the patient. 
Rather, the primary physician and the patient see only the written report 
25 generated by the interpreters who examined the images at the central 
location. In addition, this approach is based on specialized "workstations" 
(which require substantial training to operate) to send the images to the 
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central location and to view the images at the central location. It would be 
advantageous to allow the primary physician and the patient to view the 
images at other locations, such as the primary physician's office, at the 
same time he/she and the patient see the written report and without 
5 specialized hardware or software. 

In principle, medical images could be converted to Internet web pages 
for widespread viewing. Several technical limitations of current Internet 
standards, however, create a situation where straightforward processing of 
the image data results in images which transfer across the Internet too 

10 slowly, lose diagnostic information, or both. One such limitation is the 
bandwidth of current Internet connections which, because of the large size 
of medical images, result in transfer times which are unacceptably long. 
The problem of bandwidth can be addressed by compressing the image data 
before transfer, but compression typically involves loss of diagnostic 

15 information. In addition, due to the size of the images the time required to 
process image data from an original format to a format which can be viewed 
by Internet browsers is considerable, meaning that systems designed to 
create web pages "on the fly" introduce a delay of seconds to minutes while 
the person requesting to view the images waits for the data to be processed. 

20 Workstations allow images to be reordered or placed "side -by- side" for 
viewing but again an Internet system would have to create new web pages 
"on the fly" which would introduce further delays. Finally, diagnostic 
interpretation of medical images requires the images are presented with 
appropriate brightness and contrast. On proprietary workstations these 

25 parameters can be adjusted by the person viewing the images but control 
of image brightness and contrast are not features of current Internet 
standards (http or html). 
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It is possible to allow browsers to adjust image brightness and 
contrast, as well as other parameters, using "Java" programming. "Java" 
is a computer language developed by Sun Microsystems specifically to allow 
programs to be downloaded from a server to a client's browser to perform 
5 certain tasks. Using the "Java" model, the client is no longer simply using 
the browser to view "static" files downloaded from the server, but rather in 
addition the client's computer is running a program that was sent from the 
server. There are several disadvantages to using "Java" to manipulate the 
image data. First, the user must wait additional time while the "Java" code 

10 is downloaded. For medical images the "Java" code is extensive and 
download times are long. Second, the user must train to become familiar 
with the controls defined by the "Java" programmer. Third, the user must 
wait while the "Java" code processes the image data, which is slow because 
the image files are large. Fourth, "Java" code is relatively new and often 

15 causes browsers to "crash". Finally, due to the "crashing" problem "Java" 
programmers typically only test their code on certain browsers and 
computers, such as Microsoft Explorer on a PC, precluding widespread use 
by owners of other browsers and other computer platforms. 

Wood et al. (US005891035) describe an ultrasound system which 

20 incorporates an http server for viewing ultrasound images over the Internet. 
The approach of Wood et al., however, creates web pages "on the fly" 
meaning that the user must wait for the image processing to complete. In 
addition, even after processing of the image data into a web page the 
approach of Wood et al. does not provide for processing the images in such 

25 as way that excessive image transfer times due to limited bandwidth are 
addressed or provide for "brightness/ contrast" to be addressed without loss 
of diagnostic information. In addition, the approach of Wood et al. is 
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limited to ultrasound images generated by scanners manufactured by a 
single company (ATL), and does not enable viewing of images from 
modalities other than ultrasound. 

Fig. 1 summarizes a common prior art approach currently used by 
5 companies to serve medical images to Internet browsers (e.g. General 
Electric's "Web-Link" component of their workstation-based "Picture 
Archiving and Communication System" (PACS)). As can be seen in Fig. 1, 
serial processing of image data "on the fly" combined with extensive user 
interaction results in a slow, expensive, and unstable system. 

10 Referring to Fig. 1, after a scanner acquires images (Step 100) a user 

may request single image as a webpage (Step 200) whereby the image data 
is downloaded (Step 300) to allow the user to view a single image with the 
single image (Step 400). Steps 1000-1400 result in extensive user 
interaction which results in the system being slow, expensive and unstable. 

15 While the present invention relates to medical imaging generally, it 

will be better understood within the discussion of exemplary embodiments 
directed toward cardiac imaging. 

SUMMARY OF THE INVENTION 

20 The current invention proceeds from the realization that if medical 

images of different formats could be processed in such a way that 
limitations of current Internet standards could be overcome, any standard 
Internet browser could be used as a diagnostic workstation to allow any 
medical image to be viewed from any location on earth without specialized 

25 hardware or software. Once this goal has been achieved the following 
actions becomes possible: 
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1) to notify the primary physician via e-mail or pager as soon as the 
imaging has been completed; 

2) for the primary physician to view the images with a single "double 
click"; 

5 3) to view the images at the same time the primary physician and /or 

the patient reads the written report; 

4) to view images of the same patient but from different modalities 
side-by- side; 

5) to view images of the same patient and same modality but 
10 different time points side-by-side to assess the progression of 

disease; 

6) for the primary physician to discuss the images over the 
telephone with another physician who is viewing the same images 
simultaneously at another location; 

15 7) to make diagnoses and clinical treatment plans from anywhere in 

the world including the physician's home; 

8) to discuss the images with the patient in the physician's office or 
over the telephone with the patient at home; 

9) for the patient to present the images to another physician for a 
20 second opinion; 

10) for the patient to move to a different city/ state /country and have 
the images "move" with him/her. 

Furthermore, once the standard Internet browser can be used as a 
diagnostic workstation it becomes feasible to construct a world-wide 
25 database of medical images using a predefined hierarchical Internet 
addressing structure. This structure would allow for the unique address 
of all medical images for all persons throughout their lifetime. 
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Accordingly, one embodiment of the invention is directed toward a 
method of managing medical images. A plurality of medical images created 
by a plurality of medical imaging devices, each of which processes the 
medical image using a unique image format, is received. The medical 
5 images are then converted to a common image format suitable for display 
on a computer screen. Preferably the method comprises posting the 
converted images for access via a client computer. Browser compatible 
pages having embedded tags corresponding to the converted images are 
preferably generated and posted with the converted images. 

10 Another embodiment of the invention is directed towards a medical 

image database comprising images corresponding to a plurality of different 
modalities. The database is preferably organized in a hierarchical data 
structure where the data structure comprises a patient identifier parameter 
and an image modality identifier parameter. The image identifier 

1 5 parameter is associated with at least one of the plurality of modalities. The 
patient identifier parameter is preferably at a higher level in the hierarchical 
data structure than the image modality identifier parameter. 

In one method of managing medical images according to the present 
invention, images are pulled from a scanner in response to a user request. 

20 The pulled images are converted to a common image format compatible for 
display at a computer. The converted images are then posted for display 
at a client computer. Preferably the method includes displaying to a user 
at the client computer a selection comprising images associated with at 
least two different modalities. The method also preferably comprises 

25 simultaneously displaying on a screen a medical image to a first user at a 
first location and a second user at a second location. 



A medical image system, according to the present invention, 
comprises a medical image management system. In a preferred 
embodiment the medical image management system comprises a transfer 
engine for receiving image data from a scanner; a converter engine 
5 connected to receive images from the transfer engine and convert the 
images to a browser compatible format; and a post engine connected to 
receive images from the converter engine and post the images for 
subsequent access by a user. 

In a preferred embodiment, the converter engine comprises a 
10 decoding engine for extracting raw image data; and a physiologic knowledge 
engine adapted to receive data from the decoding engine. The physiologic 
knowledge engine adjusts the image quality and reduces the size of the 
image data, which is then transferred to a post engine. The physiologic 
knowledge engine is primarily responsible for reducing the image file size 
15 without loss of diagnostic data though other aspects of the invention are 
used to reduce file size while maintaining viability of the data. The 
encoding engine converts the image data to browser compatible image data. 

Other objects and advantages of the present invention will be 
apparent to those of skill in the art from the teachings herein. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the interest of enabling one of skill in the art to practice the 
invention, exemplary embodiments are shown and described. For clarity, 
details apparent to those of skill in the art and reproducible without undue 
25 experimentation are generally omitted from the drawings and description. 

Fig. 1 depicts a prior art method for user to view images from a 
scanner. 
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Fig. 2 depicts a block diagram of an imaging managing system 
according to an embodiment of the present invention. 

Fig. 3 depicts a system overview of an embodiment of the present 
5 invention for providing a user with images from a scanner. 

Fig. 4A depicts steps for affecting transfer of images from a scanner. 
Fig. 4B depicts an alternate method for obtaining images from a 
scanner via a disk having the images stored thereon. 

Fig. 5A depicts a method for extracting raw pixel data from a 
10 standard image data format. 
O Fig. 5B depicts a method for extracting raw pixel data from a non- 

Nf standard image format. 

PJ Fig. 6 depicts a method for reducing image data files without loss of 

y i 

%J diagnostic data. 

g" 15 Fig. 7 A describes a method for reducing image data file size without 

Uj loss of diagnostic information. 

^ Fig. 7B pictorially depicts selecting a bright pixel in a diagnostic 

jjr? search region. 

Fig. 7C depicts the diagnostic search area in both representative 
20 thumbnail size and full screen size with corresponding file sizes indicated. 

Fig. 8 depicts steps for converting the image to a browser compatible 
format. 

Fig. 9 depicts a method for posting the browser compatible image to 
a database. 

25 Fig. 10 is a diagram of a file structure for a web compatible database. 

Fig. 1 1 depicts a possible interface structure for accessing web 
compatible database via the Internet. 
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Fig. 12 depicts a method for displaying an image stored on a web 
compatible database accessible via the Internet. 

Fig. 13 depicts a selection of modalities for a patient, namely Doe, 

John. 

Fig. 14 shows a image identification data obtained from a separate 
file displayed with the medical image. 

Fig. 15 depicts a web page comprising ECG medical image data. 

Fig. 16 depicts MRI medical image. 

Fig. 17 depicts SPECT medical image data. 



DESCRIPTION OF EXEMPLARY EMBODIMENTS 

The present invention is discussed in relation to imaging with specific 
applications discussed in relation to cardiac images, however, other uses 
will be apparent from the teachings disclosed herein. The present invention 
15 will be better understood from the following detailed description of 
exemplary embodiments with reference to the attached drawings, wherein 
like reference numerals and characters refer to like parts, and by reference 
to the following claims. 

The herein-described invention has been constructed and tested on 
20 images of the heart acquired using a variety of modalities. The images have 
been pulled from commercial scanners, processed without loss of diagnostic 
information, adjusted with respect to brightness and contrast, and posted 
on Internet web pages for viewing. 

Figs. 2 and 3 show the process in schematic form. In Fig. 2, a 
25 medical image management system 10 is connected via a hospital intranet 
or the Internet 12 to a number of browsers 14 (such as Microsoft Explorer 
or Netscape Navigator). The connection 12 to the browsers is used to: 1) 
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accept commands to pull images from the scanners 16; 2) to navigate 
through images which have already been posted as web pages; and 3) to 
arrange and organize images for viewing. The medical image management 
system 10 is also connected to a number of medical imaging systems 
5 (scanners) 16 via a hospital intranet or the Internet 12\ The connection 
12' to the scanners 16 is used to pull the images by Internet- standard file 
transfer protocols (FTP). Alternatively, images can be transferred to the 
system 10 via a disk drive or disk 18 (see Figs. 2 and 3). 

Preferably the scanner, and hence modality, is associated with 

10 magnetic resonance imaging, echocardiographic imaging, nuclear 
scintigraphic imaging (e.g., SPECT single photon emission computed 
tomography), positron emission tomography, x-ray imaging, and 
combinations thereof. 

Responsibility for the entire process is divided amongst a series of 

15 software engines. The processes of the transfer engine 20, decoding engine 
22, physiologic knowledge engine 24, encoding engine 26, and post engine 
28 (Figs. 2 and 3) are preferably run automatically by computer and do not 
require the person using the browser, the user, to wait for completion of the 
associated tasks. The decoding engine 22, physiologic knowledge engine 

20 24, and encoding engine 26 are, preferably, combined to form a converter 
engine. The post engine 28 sends an e-mail notification, via an e-mail 
server 30 (Fig. 2) to the person submitting the request when the 
computations are complete, thereby allowing the requester to do other 
tasks. Similarly, text messages could be sent to a physician's pager. The 

25 time necessary for these computations depends on the size of the images 
and the speed of the network, but was measured for the MRI images of Fig. 
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16 to be approximately 3 minutes over a standard ethernet 10BASET line 
(10 Mbps) using a 400 MHz computer. 

The transfer engine 20 is responsible for pulling the images from the 
scanner 16 for example, in response to a user request (Step 2010). (Figs. 
5 2 and 3, details in Fig. 4). Using previously recorded information such as 
username and password, (Step 2020) the transfer engine 20 logs into the 
scanner 16 over the Internet 12 (Step 2030) and pulls the appropriate 
images from the scanner 16 using standard Internet FTP or DICOM 
commands (Step 2040). Alternatively, images can be acquired by the 

10 transfer engine 20 by use of a disk drive 18 such as a CD-ROM (Figs. 2-4) 
(Steps 201 1-2022). When the transfer process is complete, all images from 
the scan will exist within the transfer engine 20 but are still in their original 
digital format. This format may be specific to the scanner 16 manufacturer, 
or may be one of a variety of formats which are standard but cannot be 

15 displayed by browsers, such as DICOM. The images are then passed to the 
decoding engine (Step 3000). 

The decoding engine 22 (Fig. 5) is responsible for extracting the raw 
image pixel data from the original, differing, non-web compatible digital 
formats that the transfer engine 20 acquired. In the case of standard 

20 formats such as DICOM, this can be accomplished by reading published file 
structures and writing computer code to read this format (Steps 3010- 
3020). In the case of non-standard formats, successful extraction of the 
image data proceeds from the realization that all formats differ from each 
other mainly in the header region of the image file, i.e., the part which 

25 contains information like the patient name, scan date, name of hospital, 
etc. (Steps 301 1-3021.) Because the most important information such as 
patient name and scan date can be input via the web-based form pages 
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upon submission (see Figs. 14-17, for example), extraction of the image 
data for non-standard formats can be accomplished by ignoring the header 
data entirely and reading only the image data. Typically, the image data are 
stored as a series of pixel values starting at the upper left corner of the 
5 image and proceeding across each row of pixels from left to right and then 
repeating this process for all rows of the image (i.e. top to bottom). 

The physiologic knowledge engine 24 (Fig. 6) is responsible for 
adjusting image brightness and contrast, adjusting image magnification, 
adjusting movie frame speed, and other image parameters important for 
10 diagnosis (Step 4010-4020). The physiologic knowledge engine 24 is also 
O responsible for reducing the size of the images to allow acceptable transfer 

times at current Internet bandwidths without loss of diagnostic information 
Rj (Step 4030). These tasks are achieved in part by the use of a priori 

SJ knowledge of physiology, anatomy, the diagnostic question, or any 

]T" 15 combination of the three. One aspect of this is the realization that the 
Ul human eye is capable of distinguishing less than 256 distinct levels of gray 

yf in a medical image, and that most of the field-of-view (FOV) of the image is 

^ not of diagnostic interest. The grayscale limitations of the human eye 

imply that any medical image can be compressed to 8 -bits of grayscale 
20 levels and that, if appropriately scaled, the resulting image will have 
appropriate brightness/contrast without the need to adjust these using the 
web browser (Fig. 7A, Step 4020). This is important because adjustment 
of brightness/ contrast by the browser is not part of existing Internet 
standards. Another important piece of a priori information is that much 
25 of the FOV is not of diagnostic interest. (Step 4030 and Fig. 7B) This 
implies that the images can be cropped which allows a significant reduction 
in the size of the image file. This is important because limitations of 
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existing Internet bandwidths result in excessive image transfer times if the 
file size is not reduced. 

An example of how the physiologic knowledge engine 24 functions is 
given in Figs. 7A-7C for the specific case of MRI of the heart. In STEP 
5 4020, the region of the image which contains the organ of diagnostic 
interest is defined (e.g. the heart). For the general case of a group of 
images which are intended to be played as a movie to depict time-varying 
quantities (e.g. heart motion), the physiologic knowledge engine 24 searches 
all movie frames for the single brightest pixel within the search region (e.g. 

10 within the heart). All pixels of all movie frames are then scaled such that 
the single brightest pixel within the search region of all frames equal 255 
(e.g. 8-bit image). After this step, the image brightness/ contrast are 
appropriate for the organ of interest without loss of diagnostic information. 
In STEP 4030, thumbnail movies are extracted for which the FOV is 

15 reduced by cropping the images to contain only the organ of interest (e.g. 
the heart). For a typical file size of 2,000 KB for a movie with 16 frames, 
the processes herein described would result in a 20-fold reduction in movie 
file size for the thumbnails (to 100 KB) and 6-fold for full FOV images (to 
400 KB). (See Fig. 7C.) These file sizes imply that every still-frame and 

20 every movie from an entire patient scan can be transferred over the Internet 
as thumbnails in a few seconds. 

In STEP 4040, the frame rate is chosen to simulate real-time motion 
(e.g. a beating heart would have all frames play within one heart beat or 
about 1 second). In STEP 4050, full FOV images are created with a 

25 magnification which fills the user's entire screen because this is what a 
cardiologist would like to see for a heart image. Each thumbnail can be 
"clicked* by the mouse to initiate transfer of the entire FOV for that movie, 
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also in a few seconds. Importantly, this is achieved without loss of 
diagnostic information, without the need to adjust brightness /contrast, and 
without the need to adjust the frame rate of the movie. Step 4060 
comprises adjusting other parameters, if warranted. When the physiologic 
5 knowledge engine 24 has completed these tasks on all images from a given 
patient, they are passed to the encoding engine 26. 

The encoding engine 26 (Fig. 8) is responsible for converting the 
images from the raw pixel format to a new format which can be displayed 
by browsers 14. (Step 5010-5020.) One such format is the graphics 
10 interchange format (GIF), which can be used to display images in gray scale 
or color with or without animation (movies). The conversion is achieved 
using published definitions of web-compatible image formats and writing 
appropriate computer code. The images are then saved to disk and the post 
engine 28 is called. 

15 The post engine 28 (Fig. 9) is responsible for generating the html 

pages within which the images will be displayed. (Steps 6010-6030.) 
These html pages may contain coding to display text such as the patient 
name, exam date, etc. (Step 6040.) In addition, the html page will contain 
html-standard image tags which instruct the browser 14 to display the 

20 converted images. The methods by which the html pages are constructed 
and the image tags embedded are standard to the Internet and are 
published elsewhere. The final responsibilities (Step 6050) of the post 
engine 28 are: 1) to transfer the completed html pages and the converted 
images to the Web-Compatible Database 32 (Figs. 2 and 3, details Fig. 10) 

25 located on the "http Server" 34 for viewing over the Internet; and 2) to send 
e-mail notification to the physician (or technician) via the e-mail server 30 
(Fig. 2) stating that the images have been posted; and 3) providing the http 
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address for the images within the e-mail message such that the physician 
can "double-click" to immediately view the images. 

Once the images are posted as web pages, additional web pages can 
be used to allow the technician or physician to rearrange the order of the 
5 images on the web page according to the diagnostic question. For example, 
echocardiographic images are often acquired before and after a drug to 
increase heart rate has been given (e.g., dobutamine). The images before 
and after the administration of dobutamine are best viewed side-by- side for 
comparison. Arranging the images side-by-side can be achieved by allowing 

10 the user to select images using html standard web page "forms." The form 
data can then be submitted using web-standard Common Gateway Interface 
(CGI) protocols and processed by the server using a CGI program written 
specifically for this purpose. The CGI program could then create a new web 
page in which the image containers are arranged side-by- side and the html 

15 "image tags" are set to point to the images defined by the user. 
Rearrangement of the images occurs very quickly because the images do not 
require further processing or transfer across the internet. 

Fig. 1 1 shows how the Web-Compatible Database 32 of Fig. 10 can 
be used as the basic building block of a world-wide database which can be 

20 interrogated from any location on earth, for example, using any browser 14. 
In practice, some form of security such as password protection would be 
provided to prevent unauthorized viewing of the image data. 

As shown in Fig. 10, the database 32 is constructed as a hierarchical 
directory-tree with the patient's name 36 at a higher level than the modality 

25 38. Within each modality subdirectory, a series of directories with names 
corresponding to the scan date 40 would appear to allow for serial 
examinations over the patient's lifetime. 
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Using this type of structure, one can now define a hierarchical 
Internet addressing system in which any image from any modality for any 
person acquired on any date will have an unique, pre-determined Internet 
address. For example, the hierarchical address could involve first the social 
5 security number of the patient, then the imaging modality, followed by the 
scan date. (See Fig. 12, Step 7010, for example.) With this scheme, if a 
child were born in the U.S. on July 11, 2015, assigned a social security 
number of 123456789, and later scanned by MRI on September 23, 2027, 
everyone in the world would know a priori that those images will be located 
10 at Internet address: 

http://www.imagedatabase.com/usa/123456789/mri/23sep2027 
Further, it is a priori known that any MRI images of that patient taken 
anywhere, anytime in his/her lifetime are listed by scan date at: 

http://www.imagedatabase.com/usa/ 123456789/mri 
15 and further that all images of any modality that have ever been acquired of 
that patient in his/her lifetime are listed at: 

http://www.imagedatabase.com/usa/ 123456789 

The section of the URL "www.imagedatabase.com" refers to the 
company offering to serve the images over the Internet. Such a company 
20 would not process the images in any way because the images have already 
been processed as described herein. Rather, the sole function of such a 
company is to provide computing hardware which reads the "static" image 
data from a hard disk and pushes the data over the Internet (note that both 
still- frame images and movies are contained in "static" computer files). 
25 Because the images are already stored in the format of Internet web pages, 
no processing of the data is required resulting in maximum speeds for 
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image access and transfer and ensuring minimum cost for the overall 
system. 

In fact, specialized computers which are capable of no function other 
than reading from a hard disk and pushing the data over the Internet 
5 already exist and could easily be assembled into a array of servers providing 
access to an extremely large amount of data over the Internet for minimum 
cost. For example, currently a commercial system of this type provides 120 
GB of storage for $3000. With 10 MB of image data per patient scan 
(typical), this system would provide permanent Internet access to 12,000 

10 complete MRI patient scans for a cost of 25 cents each (exclusive of 
electrical and maintenance costs). Importantly, this type of world-wide 
database would be difficult if not impossible to construct if the processes 
described herein were not employed. 

Fig. 12 shows how a user's request to view images (Step 7010) would 

15 be processed (Steps 7020-7040) by the world-wide database system of Fig. 
1 1 using the basic building block of Fig. 10. Fig. 13 shows the resultant 
web page 40 displaying in response to a user sending a request to view 
"/Doe, John" via a browser 14. Fig. 14 shows the result of clicking on 
"Cath" 42 (see Fig. 13) followed by clicking on the scan date (not shown). 

20 Identification data 43 is displayed with the image 44 corresponding to the 
examination data indicated. The html page 40' and the embedded images 
44 are sent by the http server 34 to the browser 14. The images 44 can be 
still frames or movies depending on how they were originally acquired by 
the scanner 16. In the case of movies, animated GIF format can be used 

25 by the encoding engine 26. Figs. 15, 16, and 17 show the result of 
clicking on ECG, MRI, and SPECT, respectively. The time necessary to 
transfer the images 44 from the http Server 34 to the browser 14 will 
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depend on the size of the images 44 and the speed of the network, but was 
measured to be approximately 3 seconds for the entire set of MRI images of 
Fig. 16 over a standard ethernet 10BASET line (note that the top row of MRI 
images in Fig. 16 are movies displaying heart contraction). 
5 Thus, using the current invention a database of images can be 

constructed with maximum Internet performance and without loss of 
diagnostic information. Importantly, the processes described herein allow 
viewing of images from multiple modalities side-by-side by the primary 
physician and/ or the patient. Further, the database structure facilitates 

10 the storage of image data from multiple modalities and multiple scans over 
a patient's lifetime in a single location identified by the patient's name, 
social security number, or other unique identifier. This ability would be 
expected to significantly enhance the ability of the primary physician to 
determine the course of action which is in the best interest of the patient. 

15 While the invention has been particularly shown and described with 

reference to particular embodiments thereof, it will be understood by those 
skilled in the art that various changes in form and detail may be made 
therein without departing from the spirit and scope of the invention. The 
scope of the claimed invention is intended to be defined by following claims 

20 as they would be understood by one of ordinary skill in the art with 
appropriate reference to the specification, including the drawings, as 
warranted. 



